PCT/AT 2004/00040 8 




Bescheinigung Certificate Attestation 



Die angehefteten Unterla- 
gen stimmen mlt der 
ursprunglich eingereichten 
Fassung der auf dem nSch 
sten Blatt bezeichneten 
europaischen Patentanmel- 
dung Qberein. 



The attached documents 
are exact copies of the 
European patent application 
described on the following 
page, as originally filed. 



Les documents fixes a 
cette attestation sont 
conformes a la version 
initialement deposee de 
la demande de brevet 
europeen specifiee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n° 

03450257.5 



i PRIORITY 
DOCUMENT 

I SUBMITTED OR TRANSMITTED IN 
! COMPLIANCE WITH RULE 17.1(a) OR (b) 



Der President des Europaischen Patentamts; 
Im Auftrag 

For the President of the European Patent Office 

Le President de 1'Office europeen des brevets 
p.o. 




R C van Dijk 



REST AVAILABLE COP Y 

EPA/EPO/OEB Form 1014.1 - 02.2000 7001014 



Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Anmeldung Nr; 

Application no.: 03450257.5 
Demande no: 



Anmeldetag: 

Date of filing: 21. 11.03 
Date de depot: 



Anmel der/Appl 1 can t( s)/Demandeur( s) : 

Neswal, Peter 

Lassallestrasse 14 

2231 Strasshof an der Nordbahn 

AUTRICHE 



Bezelchnung der Erf 1 ndung/Tl tl e of the 1nvent1on/Tl tre de l 1 Invention: 
(Falls die Bezelchnung der Erflndung nlcht angegeben 1st, slehe Beschrel bung. 
If no title Is shown please refer to the description. 
SI aucun tltre n'est 1nd1qu€ se referer & la description.) 

Verfahren zur Installation und Konf iguration von Sof twarekomponenten 

In Anspruch genommene Pr1or1at(en) / Pr1or1ty(1es) claimed /Pr1or1t6(s) 
revendlquee(s) 

Staat/Tag/Aktenze1chen/State/Date/F1le no./Pays/Date/Numero de depdt: 



Internationale Patentklasslf 1 katl on/International Patent Classification/ 
Classification Internationale des brevets: 



Am Anmeldetag benannte Vertragstaa ten/Contracting states designated at date of 
fUlng/Etats contractants designees lors du depot: 

AT BE BG CH GY CZ DE DK EE ES FI FR 6B GR HU IE IT LU MC NL 
PT R0 SE SI SK TR LI 



03450257.5 

EPA/EP0/0EB Form 1014.2 - 01.2000 7001014 



G06F9/40 




Verfahren zur Installation und Konf iguration 

von Softwarekomponenten 

Die vorliegende Erfindung betrifft ein Verfahren zui 
5 automat ischen Installation und Konf iguration von Sof twarekompo- 
nenten in einem Computernetzwerk, das eine Vielzahl von Benut- 
zerrechnern und zumindest eine Netzwerkressource von instal- 
lierbaren Sof twarekomponenten umfafct, wobei die erfolgreich* 
Installation einer Sof twarekomponente die An- oder Abwesenheit 

10 einer anderen Sof twarekomponente voraussetzen kann. Die Erfin- 
dung betrifft ferner Computerprogrammobjekte zur Durchfiihrunc 
dieses Verfahrens in Form eines Regelpakets, eines Frameworks 
und eines Klientprogramms, sowie Computer und Datentrager, die 
mit solchen Programmobjekten programmiert sind. 

15 Die Verteilung, Installation und Konf iguration vor 

Sof twarekomponenten in grofteren Computernetzwerken, z.B. Fir- 
mennetzwerken mit Tausenden von unterschiedlichen Benutzerrech- 
nern, auf denen Hunderte von Softwarekomponenten laufen, die 
ttberdies teils unterschiedlich zu konf igurieren sind, ist ir 

20 der Praxis ein nicht-triviales Problem. 

Zur L&sung dieses Problems wurden bereits verschiedenste 
Mechanismen vorgeschlagen, denen alien gemeinsam ist, daft sie 
von einer zentralen Verteilung der Softwarekomponenten ausge- 
hen. Dies erfordert einerseits genaue Kenntnis liber die Aus- 

25 stattung und Anf orderungsprof ile aller Benutzerrechner im Feld, 
was den Aufbau und die Verwaltung umf angreicher Verzeichnisse 
und Verteilungsschltissel bedeutet. Andererseits konnen zentra- 
len Verteilungsstrategien nicht auf rasche Vor-Ort-Ver3nderun- 
gen der Hard- Oder Sof twareausstattung oder der Konf iguratior 

30 eines Benutzerrechners reagieren, wie das Anschlieften neuei 
Hardware , das Anmelden in einem Netzwerk, das Anmelden eines 
Benutzers usw. 

Die Erfindung setzt sich zum Ziel, Verfahren, Programmob- 
jekte und gemaB diesen programmierte Computer und Datentragei 
35 zu schaffen, mit denen Softwarekomponenten in einem groftmafista- 



2 



bigen Contputernetzwerk verteilt, installiert und individuell 
konf iguriert werden konnen, und dies mit minimalem Verwaltungs- 
aufwand, gr6fttmoglicher Flexibilitat und rascher Reaktion auf 
lokale Anderungsereignisse an den Benutzerrechnern. 
5 Dieses Ziel wird in einem ersten Aspekt mit einem Verfah- 

ren der einleitend genannten Art erreicht, das sich gemafi der 
Erfindung auszeichnet durch die Schritte: 

a) Bereitstellen eines Frameworks auf der Netzwerkres- 
source, welches ein Regelpaket far jede instailierbare Soft- 

10 warekomponente, einen Detektor fttr jede mSgliche Voraussetzung 
und eine Liste abzuarbeitender Regelpakete umfaftt, 

wobei jedes Regelpaket zumindest eine der folgenden vier 
Routinen umfaftt: eine Routine zum Installieren der Softwarekom- 
ponente auf dem Benutzerrechner, eine Routine zum Deinstallie- 

15 ren derselben, eine Routine zum Konf igurieren der installierten 
Sof twarekomponente und eine Routine zum Ruckgangigmachen (De- 
konf igurieren) der Konf iguration hinsichtlich derselben; 

b) Obertragen des Frameworks an einen Benutzerrechner; 

c) Abarbeiten der Liste abzuarbeitender Regelpakete auf 
20 dem Benutzerrechner unter Aufrufen ihrer Installationsroutinen f 

und nochmaliges Abarbeiten der Liste abzuarbeitender Regelpa- 
kete auf dem Benutzerrechner unter Aufrufen ihrer Konfigurati- 
onsroutinen; 

wobei, wenn im Zuge eines Regelpakets mittels eines Detek- 
25 tors festgestellt wird, daft die An- Oder Abwesenheit einer an- 
deren Sof twarekomponente erforderlich ist, die Installations- 
bzw. Deinstallationsroutine des dieser anderen Sof twarekompo- 
nente zugeordneten Regelpakets aufgerufen wird. 

Auf diese Weise wird erstmals eine automatisierte, dezen- 
30 trale und dynamische Selbstinstallation und -konf iguration je- 
des einzelnen Benutzerrechner s mSglich, welche rasch auf lokale 
Ereignisse reagieren kann. Jeder Benutzerrechner erhalt ein 
Framework aus Regeln in Form von Regelpaketen, die alien poten- 
tiell installierbaren Sof twarepaketen zugeordnet sind. Dadurch 
35 wird eine zentrale Verteilung von Softwarekomponenten mit all 
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den beschriebenen Nachteilen vermieden; lediglich eine Abbil- 
dung der gegenseitigen Abhangigkeiten aller installierbarei 
Sof twarekomponenten wird in Form des Frameworks verteilt. 

Die Sammlung und Wartung zentraler Verzeichnisse tiber di< 
5 Ausstattung und Konf iguration aller Benutzerrechner entfallt. 
Der Aufbau des erf indungsgemafien Frameworks ist wesentlich ein- 
facher, da hier nur einmal fur jede installierbare Softwarekom- 
ponente ihr Einsatzgebiet und ihre Anforderungen zu definierei 
sind. Dazu stellt das Framework auch wiederverwendbare Detekto- 

10 ren zur Verftigung, mit deren Hilfe die Voraussetzungen ftir di« 
Installation oder Konf iguration einer Sof twarekomponente auJ 
dem Benutzerrechner rasch ttberprtift werden konnen. 

Die Regelpakete fur die einzelnen Sof twarekomponenten sine 
ausschlieJJlich tiber ihre gegenseitigen Abhangigkeiten referen- 

15 ziert, sonst aber autark. Dies erleichtert einerseits die Defi- 
nition der Regelpakete ftir die Bereitstellung des Frameworks, 
andererseits brauchen die Regelpakete auf dem Benutzerrechnei 
nur eines nach dem anderen abgearbeitet zu werden, wobei si* 
sich entsprechend ihrer Abhangigkeiten auch gegenseitig aufru- 

20 fen kdnnen. Jedes Regelpaket „weifi" selbst, wie es seine zuge- 
ordnete Sof twarekomponente installieren, deinstallieren, konfi- 
gurieren bzw. dekonf igurieren kann. Das Erzeugen von speziellei 
Installations- Oder Konf igurations-Scripts ftir die einzelner 
Benutzerrechner entfallt. 

25 Mit dem Verfahren der Erfindung ist nicht nur die Vertei- 

lung und die Installation von Sof twarekomponenten moglich, son- 
dern gleichzeitig auch ihre Konf iguration, d.h. die Einstellunc 
spezieller Parameter der installierten Sof twarekomponente . Da- 
mit kSnnen z.B. benutzerspezif ische, anwendungsumgebungsspezi- 

30 fische, gruppenspezif ische oder aber auch einfach nur firmen- 
einheitliche Konf igurationen auf alien Benutzerrechnern in 
Netzwerk durchgefiihrt werden. Alles f was dazu erforderlich ist, 
ist. die einmalige Definition eines Regelpakets fur die jewel- 
lige Sof twarekomponente. 



Eine bevorzugte Ausf uhrungsf orm des Verfahrens der Erfin- 
dung zeichnet sich dadurch aus, daft das Framework auch Detekto- 
ren fur die Hardware- oder Betriebssystemausstattung eines Be- 
nutzerrechners umfafit und im Zuge einer Routine mittels eines 
solchen Detektors uberpruft wird, ob der Benutzerrechner fur 
die jeweilige Installation, Deinstallation, Konf iguration oder 
Dekonf iguration der Sof twarekomponente geeignet ist, und/oder 
daft im Zuge einer Routine vorab gepriift wird, ob die jeweilige 
Installation, Deinstallation, Konf iguration oder Dekonfigura- 
tion der Sof twarekomponente auf dem Benutzerrechner bereits er- 
folgt ist und, wenn ja, die Routine sofort beendet wird. 

Dadurch wird jedes Regelpaket noch starker autark, d.h. es 
„weifi" auch, ob es ftir den jeweiligen Benutzerrechner zustandig 
bzw. anzuwenden ist. Die Abarbeitung der Regelpakete auf den 
Benutzerrechnern wird dadurch noch einfacher. Im allgemeinsten 
Fall konnen z.B. einfach alle im Framework vorhandenen Regelpa- 
kete abgearbeitet werden, beginnend mit dem ersten, und jedes 
Regelpaket entscheidet ftir sich, ob es tiberhaupt auszuftihren 
ist, andere, vorauszusetzende Regelpakete aufrufen soli usw. 

Wie bereits erSrtert, besteht ein entscheidender Vorteil 
des dezentralen Verfahrens der Erfindung darin, daft es beson- 
ders rasch auf lokale Anderungsereignisse am Benutzerrechner 
reagieren kann. Zu diesem Zweck wird bevorzugt vorgesehen, daft 
Schritt b) und/oder Schritt c) durch ein lokales Ereignis auf 
dem jeweiligen Benutzerrechner ausgelost wird, z.B. ein System- 
ereignis wie ein Systemstart' oder -stop, eine Benutzeran- oder 
-abmeldung, eine Netzwerkan- oder -abmeldung, ein Programmstart 
oder -ende usw., ein Hardwareereignis wie das An- oder Ab- 
schliefien einer Hardwareausstattung, usw. 

GrundsStzlich ist es auch mSglich, daft alternativ oder zu- 

satzlich Schritt b) und/oder Schritt c) durch ein entferntes 

» 

Ereignis auf der Netzwerkressource ausgelost wird, z.B. das 
Aussenden einer Gruppen- oder Broadcastnachricht usw., wodurch 
auch das Verhalten herkommlicher zentraler Verteilungsverf ahren 
mit dem erf indungsgemaften Verfahreh nachgebildet werden kann. 
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Die Erfindung erstreckt sich auch auf ein Computerprc 
gramm, welches das erf indungsgemafie Verfahren implementiert . 

Ein weiterer Aspekt der Erfindung besteht in der Schaffun 
eines Regelpakets, das auf einem Betriebssystem eines Benutzei 
5 rechners ausfiihrbar ist, wie in den Anspriichen 7 bis 11 defi 
niert. Beztiglich der Merkmale und Vorteile des erf indungsgema 
fien Regelpakets ward auf die obigen AusfUhrungen zum Verfahre 
verwiesen. 

Eine bevorzugte Ausf tihrungsf orm eines Regelpakets der Er 

10 findung zeichnet sich dadurch aus, dafi es mindestens einen Aus 
loseverweis auf ein lokales Ereignis auf deia Benutzerrechne 
oder ein entferntes Ereignis. auf der Netzwerkressource enthait 
wobei der Ausldseverweis diesem Ereignis zumindest eine , de 
Routinen des Regelpakets zuordnet* Dadurch k5nnen auch einzeln 

15 Regelpakete bzw. deren Routinen ereignisgesteuert ausgeftihr 
werden, was die Flexibilit&t und Reaktionsf ahigkeit des System 
wesentlich erh6ht. 

In der Praxis kommen standig neue Sof twarekomponenten au 
den Markt. Wenn keine besonderen Mafinahmen ergriffen werden 

20 wiirde die Anzahl der Regelpakete im Framework standig anwach 
sen; andererseits werden Regelpakete im Framework obsolet, z.B 
wenn Sof twarekomponenten auJJer Dienst gestellt werden. Solch 
obsoleten Regelpakete werden zweckmSfiigerweise aus dem Frame 
work entfernt, auf einzelnen Benutzerrechnern k6nnen sie jedoc 

25 noch erforderlich sein, beispielsweise wegen veralteter Hard 
warekomponenten. Es ist daher besonders gtinstig, wenn Regelpa 
kete auch in einen inaktiven Zustand versetzbar sind, in wel 
chem nur ihre Deinstallationsroutine aufrufbar ist* Dadurc 
kann die Installation veralteter Softwarekomponenten verhinder 

30 werden, ihre Deinstallation ist aber jederzeit m6glich. 

Die Erfindung erstreckt sich auch auf einen Computer, de 
mit zumindest einem erf indungsgemalben Regelpaket programmier 
ist. 

Ein weiterer Aspekt der Erfindung ist ein Framework, da 
35 auf einer Netzwerkressource in einem Computernetzwerk ftir ein 
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Viel2ahl von Benutzerrechnern bereitstellbar ist, wie in den 
Ansprtichen 13 und 14 definiert, und das erf indungsgem£J5e Regel- 
pakete enthalt. Beziiglich der Merkmale und Vorteile des Frame- 
works wird auf die obigen Ausfiihrungen zum Verfahren verwiesen. 
5 Die Erfindung erstreckt sich auch auf einen Computer und 

einen maschinenlesbaren Datentrager, die mit einem erfindungs- 
gemafien Framework prograramiert sind. 

Noch ein weiterer Aspekt der Erfindung besteht in der 
Schaffung eines Klientprogramms, das auf einem Benutzerrechner 

10 ausftihrbar ist, wie in den Ansprttchen 17 bis 21 definiert, und 
ein Framework gemafi der Erfindung enthalt. Beziiglich weiterer 
Merkmale und Vorteile des Klientprogramms wird auf die obigen 
Ausfiihrungen zum Verfahren verwiesen, 

Gem&B einer bevorzugten Ausf tihrungsf orm weist das Klient- 

15 programm eine lokale Datenbank auf, welche eine Liste von Re- 
gelpaketen mit erfolgreich durchlauf enen Installationsroutinen 
und eine Liste von Regelpaketen mit erfolgreich durchlauf enen 
Konf igurationsroutinen enthalt. Mit Hilfe dieser Datenbank kann 
die Abarbeitung der Regelpakete beschleunigt werden, da bei- 

20 spielsweise fiir bereits installierte oder konf igurierte Soft- 
warepakete der Aufruf der entsprechenden Regelpakete unterblei- 
ben kann . 

Oberdies erdffnet dies die M5glichkeit, dafi das Klientpro- 
gramm die in den Listen eingetragenen Regelpakete mit den im 

25 Framework enthaltenen Regelpaketen vergleicht und fur jene Re- 
gelpakete, welche im Framework nicht aufscheinen, in einem er- 
sten Durchgang deren Dekonf igurationsroutinen und in einem 
zweiten Durchgang deren Deinstallationsroutinen abarbeitet, wo- 
durch obsolete oder veraltete Software komponenten automatisch 

30 entfernt werden konnen. 

Gemafi einer bevorzugten Ausf Uhrungsform eines Klientpro- 
gramms, welches von Regelpaketen mit Ausloseverweisen zur er- 
eignisgesteuerten Ausfiihrung Gebrauch macht, uberwacht das 
Klientprogramm das Auftreten eines lokalen Ereignisses auf dem 

35 Benutzerrechner, z.B. eines Systemereignisses wie eines System- 
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starts oder -stops, einer Benutzeran- oder -abmeldung, eine. 
Netzwerkan- oder -abmeldung, eines Programmstarts oder -ende. 
usw., eines Hardwareereignisses wie des An- oder Abschlieften: 
einer Hardwareausstattung, usw., und/oder eines entfernten Er- 
5 eignisses auf der Netzwerkressource, z.B. des Aussendens eine: 
Gruppen- oder Broadcastnachricht usw., und ruft die diesem Er- 
eignis tiber den Ausloseverweis zugeordnete Routine des entspre 
chenden Regelpakets auf. Dies kann zweckmaUigerweise auch mi- 
Hilfe der Listen in der Datenbank erfolgen, in welche die Aus- 

10 loseverweise der Regelpakete miteingetragen werden konnen. Au: 
diese Weise kannen auch einzelne oder Gruppen von Regelpaketei 
bzw. deren Routinen ereignisgesteuert ausgefuhrt werden. 

In jedem Fall ist es besonders gilnstig, wenn das Klient- 
programm ein Transaktionssystem fiir jede systemmodif izierend* 

15 Komponente, insbesondere fur die Regelpakete, aufweist. Dadurc] 
kann jederzeit ein Rollback des Systems vorgenommen werden, 
wenn z.B. eine Installation oder Konf iguration fehlschl&gt, wi< 
in der Technik bekannt. Die Betriebssicherheit des Klientpro- 
gramms wird dadurch wesentlich erhoht. 

20 Schliefilich erstreckt sich die Erfindung auch auf einei 

Computer, der mit einem erf indungsgemaften Klientprogramm pro- 
grammiert ist. 

Die Erfindung wird nachstehend anhand von in den Zeichnun- 
gen dargestellten Ausftthrurigsbeispielen naher eriautert. In dei 
25 Zeichnungen zeigt: 

Fig. 1 ein Blockschaltbild eines Computernetzwerkes, ii 
welchem das Verfahren, die Programmobjekte und Computer der Er- 
findung zur Anwendung gelangen, 

Fig. 2 ein Blockschaltbild eines beispielhaf ten, mit einei 
30 Klientprogramm programmierteh Benutzerrechners der Erfindung, 

Fig. 3 den schematischen Aufbau eines Frameworks der Er- 
findung, 

Fig. 4 den schematischen Aufbau eines Regelpakets der Er- 
findung, 



Fig. 5 die gegenseitigen Beziehungen mehrerer beispielhaf ~ 
ter Regelpakete in Form eines Beziehungsdiagramms, 

Fig. 6 ein Fluftdiagramm des Verfahrens der Erfindung, 

Fig. 7 ein Beispiel ftlr die von einer Installationsroutine 
erzeugten Eintrage in der lokalen Datenbank, 

Fig. 8 ein Beispiel ftir die von einer Konf igurationsrou- 
tine erzeugten Eintrage in der lokalen Datenbank, 

Fig. 9 mehrere mSgliche Auslosearten ftir die auf dem Be- 
nutzerrechner ablaufenden Schritte des Verfahrens der Erfindung 
in Form eines Flulidiagramms, und 

Fig. 10 das Blockschaltbild einer moglichen Implementie- 
rung des Klientprogramms auf einem Betriebssystem mit voneinan- 
der isolierten Ausfuhrungsschichten. 

Fig. 1 zeigt ein Computernetzwerk 1, das eine Vielzahl von 
Benutzerrechnem 2 umfaflt. Ein beispielhaf ter Benutzerrechner 2 
ist in Fig. 2 ausf tihrlicher gezeigt und enthalt eine Anzahl von 
schematise!! dargestellten Sof twarekomponenten BSl f A f B, . • , 
welche je nach Einsatzgebiet des Benutzerrechners 2 rechner- f 
benutzer- oder anwendungsspezif isch installiert und konfigu- 
riert werden sollen. 

Die Gesamtheit aller auf dem Benutzerrechner 2 potentiell 
installier- und konf igurierbarer Sof twarekomponenten ist in 
Fig. 2 mit SW bezeichnet. Dabei ist zu beachten, daft die In- 
stallation und Konf iguration der Sof twarekomponenten SW komple- 
xen gegenseitigen Abhangigkeiten unterworfen sein kann. Bei- 
spielsweise erfordert die Installation der Sof twarekomponente B 
eine vorherige Installation der Sof twarekomponente A und diese 
wiederum eine vorherige Installation der Sof twarekomponente 
BS1, welche z.B. bereits auf dem Benutzerrechner 2 installiert 
sein kann, weil sie Teil des Betriebssystems ist. Andererseits 
kann es Sof twarekomponenten geben, welche unbedingt die Abwe- 
senheit, d.h. Deinstallation, einer anderen Sof twarekomponenten 
fur ihre korrekte Installation voraussetzen. Eine solche Situa- 
tion ist in Fig. 5 dargestellt (welche spater noch ausftthrli- 
cher erortert wird) , wobei die mit „restrict" bezeichneten 
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Pfade zwischen Sof twarekomponenten die Voraussetzung der Abws 
senheit einer Sof twarekomponente angeben, jene mit ^require 
bezeichneten Pfade die Voraussetzung der Anwesenheit eim 
Sof twarekomponente . 
5 Es versteht sich f dafi der Begriff „ Sof twarekomponente v 

wie er hier verwendet wird, je nach Anwendungsf all und Erfoi 
dernis jede Art von Granular itat bzw. „Korngr6fle^ von Softwai 
umfaBt, sei es ein Treiber, ein Unterprogramm, ein Programmofc 
jekt, ein Hauptprogramm, eine Unter- oder Hauptklasse, eine Ar. 

10 wendung, oder ein Anwendungskomplex. Darin zeigt sich die Mach 
tigkeit der hier vorgestellten L5sung: So kann z.B. ein Regel 
paket RPi ftir die allgemein bekannte Sof twarekomponente w Micrc 
soft Office XP mit Microsoft Frontpage, ohne Netzwerkunterstat 
zung %% definiert werden, gleichzeitig ein weiteres Regelpake 

15 RP 2 fur die - sich teilweise uberlappende, teilweise unterfal 
lende - Sof twarekomponente ^Microsoft Frontpage, mit Netzwerk 
unterstutzung'' . 

Zuruckkehrend auf Fig* 1 wird das gesamte Beziehungssyste 
aller potentiell auf den Benutzerrechnern 2 installierbare 

20 Sof twarekomponenten SW in Form eines Frameworks FW abgebildet 
dessen struktureller Aufbau spater noch ausfuhrlicher unter Be 
zugnahme auf die Fig. 3 und 4 erlautert wird. Das Framework F 
wird im Computernetzwerk 1 auf einer Netzwerkressource RES X be 
reitgestellt . 

25 Unabhangig von dem Framework FW werden im Computernetzwer 

1 auf einer weiteren Netzwerkressource RES2 alle potentiell in 
stallierbaren Sof twarekomponenten SW (BS1, A, B, . . ) bereitge 
stellt, 

Es versteht sich, dafi die Netzwerkressourcen RESi und RES 
30 auch ein und dieselbe Netzwerkressource RES sein konnen (sieh 
z.B. Fig. 2) oder ihrerseits in geographisch verteilte Netz 
werkressourcen aufgeteilt werden konnen (siehe z.B. die Vertei 
lung der Sof twarekomponenten A und B auf die Netzwerkressource 
RES 2 und RES 3 in Fig. 2) . Auch ist es moglich, daB eine de 
35 Netzwerkressourcen, insbesondere jene fur die Sof twarekomponen 
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ten, tatsachlich ein „of f line^-Datentrager ist, z.B. eine CD- 
Rom usw., wie in Fig. 2 beispielhaft fur die Softwarekomponente 
B angedeutet. 

Der Aufbau und die Pflege des Frameworks FW, d.h. das Ein- 
5 speisen in die Netzwerkressource RESi, werden an Administrator- 
arbeit splat zen 3 durchgef tihrt . Die Verteilung bzw. Ausbreitung 
des Frameworks FW im Computernetzwerk 1 bis zu den Benutzer- 
rechnern 2 kann auf jede beliebige Art erfolgen, beispielsweise 
durch Push-Technologien, wie Broadcast- Oder Gruppennachrichten 
10 nach dem Internetprotokoll, oder Pull-Technologien, wie Abholen 
durch die Benutzerrechner 2 von Logon-Shares auf den Netzwerk- 
ressourcen bei einem Systemstart oder einer Benutzeranmeldung, 
durch Peer-to-Peer-Propagierungs- oder Replizierungsverf ahren 
usw. 

15 Beispielsweise kann das Framework FW in der Art von Inter- 

net-Domain-Name-Services von Netzwerkknoten, wie der Netzwerk- 
ressource RESi f zu Netzwerkknoten, wie der Netzwerkressource 
RES2, mittels Spiegelung repliziert und damit verteilt werden. 
. Dadurch kann das Framework FW auch auf Netzwerkressourcen RES 2 
. 20 verfugbar sein, welche far die Bereithaltung von Sof twarekompo- 
nenten SW dienen, oder auch direkt von Benutzerrechner 2 zu Be- 
nutzerrechner 2 ( „Peer-to- Peer") repliziert werden. Urn den 
Netzwerkverkehr bei der Verteilung des Frameworks FW mdglichst 
gering zu halt en, kann auch vorgesehen werden, daJJ nach einer 

25 erstmaligen Verteilung des gesamten Frameworks FW nur mehr Dif- 
f erenz-Opdates des Frameworks FW auf seine jeweils aktuellste 
Version verteilt werden. 

Die weitere Beschreibung der Erfindung geht von einem Zu- 
stand aus, in welchem das Framework FW dem stellvertretend be- 

30 schriebenen Benutzerrechner 2 zur Verfiigung steht. 

Der Aufbau des Frameworks FW wird anhand der Fig. 3 und 4 
naher erlSutert. Gemafi Fig. 3 umfafit das Framework FW einen 
Satz von Regelpaketen RP, ' und zwar ein Regelpaket RP fur jede 
potentiell auf einem Benutzerrechner 2 installier- und/oder 

35 konf igurierbare Softwarekomponente BS1, A, B, . . Jedes Regelpa- 
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ket RP bildet die Hard- und Softwarevoraussetzungen jeweils ei 
ner Sof twarekomponente ab. 

Fig. 4 zeigt den Aufbau eines beispielhaf ten Regelpaket 
RP A fiir die Sof twarekomponente A. Das Regelpaket RP A enthal 
5 einen Verweis RES A auf seine zugeordnete Sof twarekomponente A 
beispielsweise in Form eines Zeigers auf jene Netzwerkressourc 
RES 2 / auf welcher die Sof twarekomponente A verfugbar ist. 

GemSfi Fig. 4 umfafit jedes Regelpaket RP eine Routin 
„INST()" 4 zum Installieren der ihm zugeordneten Sof twarekompo 

10 nente (hier: A) auf dem Benutzerrechner 2, eine weitere Routin 
„DEINST()" 4' zum Deinstallieren diese Sof twarekomponente vo: 
Benutzerrechner 2, eine Routine „CONFIG()" 5 zum Konfiguriere 
dieser Sof twarekomponente und eine Routine „DECONFIG ( ) * 5' zu 
Ruckgangigmachen („Dekonf igurieren") der Konf iguration diese 

15 Sof twarekomponente . 

Ein Regelpaket RP mufi nicht alle vier Routinen 4, 4', 5 
5' enthalten, jedoch mindestens eine der Routinen 4, 4' , 5, 5' 
Bevorzugt enthait das Regelpaket RP mindestens ein komplementa 
res Routinenpaar 4/4' oder 5/5', so dafi zu der Installations 

20 bzw. Konf igurationsroutine 4, 5 jeweils zumindest die zugeord 
nete Deinstallations- bzw. Dekonf igurationsroutine 4' , 5' ent 
halten ist. 

Es versteht sich, dafi die vier Routinen 4, 4', 5 und 5' 
soferne sie gemeinsame Codeabschnitte besitzen - auch strecken 

25 weise in einer gemeinsamen Routine zusammengef afit sein k5nnen 
z.B. in einer gemeinsam zu durchlaufenden Einleitungsroutin 
des Regelpakets RP r oder tiberhaupt durch einen gemeinsamen Co 
deabschnitt implement iert werden kSnnen, welcher durch entspre 
chende Auf ruf schalter gesteuert einmal z.B. die Funktion de 

30 Installationsroutine 4, ein anderes Mai z.B. die Funktion de 
Dekonf igurationsroutine 5 ' einnimrat, usw. In diesem Sinne sin 
die Routinen 4, 4', 5, 5' „f unktionelle" Routinen, nicht not 
wendigerweise Routinen im programmtechnischen Sinne, wie fii 
den Fachmann ersichtlich. 
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In der vorliegenden Beschreibung wird der Begriff „Instal- 
lieren" zum grundsatzlichen Bereitstellen der Nutzungsmoglich- 
keit einer Software komponente auf einem Benutzerrechner verwen- 
det. Die Installation umfafit in der Kegel das Speichern der 
5 Softwarekomponente A auf einem lokalen Datenspeicher (z.B. der 
Festplatte) des Benutzerrechners, sowie hSufig auch ein erstes, 
allgemeines Konf igurieren (siehe unten) der Softwarekomponente, 
damit diese grundsatzlich betriebsf Shig ist. 

Der Begriff „Deinstallieren x% wird fdr das Entfernen der 

10 Softwarekomponente SW vom Benutzerrechner 2, z.B. durch Loschen 
von der Festplatte, verwendet. 

Der Begriff „Konf igurieren" wird wiederum ftir jede Form 
von einheitlicher, gruppenspezif ischer, benutzerspezif ischer 
oder anwendungssituationsspezif ischer Einstellung einer Soft- 

15 ware komponente verwendet , wie durch den Einstellungspf eil in 
Fig. 2 versinnbildlicht . Damit ermSglicht das erf indungsgemafie 
Verfahren nicht nur die autarke Installation aller erforderli- 
chen Sof twarekomponenten auf einem Benutzerrechner , sondern 
auch die Einstellung eines bestimmten, im Framework FW defi- 

20 nierten Zustandes dieser Sof twarekomponenten. 

Unter dem Begriff „RUckgangigmachen einer Konf iguration" 
bzw. „Dekonf igurieren" wird in der vorliegenden Beschreibung 
das Wiederherstellen jener Einstellung einer Softwarekomponente 
verstanden, wie sie vor dem Kohf igurieren geherrscht hat, 

25 und/oder das Einstellen der nach einer Deinstallation dieser 
Softwarekomponente verbliebenen anderen Softwarekomponenten in 
der Art, wie es fur den aktuellen Systerazustand ohne die dein- 
stallierte Softwarekomponente erforderlich ist; letzteres ist 
auch mit dem Begriff RttckgSngigmachen der Konf iguration „hin- 

30 sichtlich" dieser Softwarekomponente gemeint. 

Gemafi Fig. 4 kann das Regelpaket RP A optional einen oder 
mehrere Ausloseverweise TRIG A auf ein lokales oder entferntes 
Ereignis enthalten, bei dessen Auftreten zumindest eine seiner 
Routinen 4, 4', 5, 5' ausgefahrt werden soli, wie spater noch 

35 anhand von Fig. 9 ausf uhrlicher erQrtert wird. 



- 13 - 

Ferner kann das Regelpaket RP A auch lokale Ressource 
RES 4 , RES 5 far z.B. kleine Softwarekomponenten oder Konfigura 
tionsparameter umfassen. 

Jede der Routinen 4, 4', 5, 5' enthalt eine eigenstandig 
5 Oberprufung der Voraussetzungen ftir die Installation, Konfigu 
ration, Deinstallation oder Dekonf iguration der dem Regelpake 
zugeordneten Softwarekomponente, beispielsweise das Erforderni 
der Anwesenheit einer anderen Sof twarekomponente („require" 

« 

Pfade in Fig. 5) oder der Abwesenheit einer Komponente („re 
10 strict "-Pfade in Fig. 5) . Wenn die jeweilige Routine ein Anwe 
senheitserfordernis („require") feststellt, ruft sie die In 
stallationsroutine 4 des dieser anderen Sof twarekomponente zu 
geordneten anderen Regelpakets RP auf; wenn sie ein Abwesen 
heitserfordernis (^restrict") feststellt, dessen Deinstallati 
15 onsroutine 4'. Auf diese Weise wird durch Abarbeiten der Regel 
pakete das Beziehungsgef lecht von Fig. 5 eingehalten und ausge 
ftlhrt. Es ist klar, dafi diese Oberpriifung auch in einen de: 
Routinen gemeinsamen Teil des Regelpakets ausgelagert sei: 
kann f welcher bei Ausfuhrung einer Routine stets durchlaufei 
20 wird. 

Urn die OberprUfung der An- oder Abwesenheit einer bestimm- 
ten Softwarekomponente zu vereinf achen, umfaftt das Framework Fl 
einen Satz von Detektionsroutinen bzw. Detektoren DET, z.B. ei- 
nen Detektor DET A fur das Vorhandensein der Softwarekomponente 

25 A, einen Detektor DET B si ftir das Vorhandensein der Betriebssy- 
stemkomponente BS1 oder einen Detektor DEThw ftir das Vorhanden- 
sein einer bestimmten Hardwareausstattung des bestimmten Benut- 
zerrechners 2, siehe Fig. 5. 

Die Detektoren DET konnen nicht nur die An- oder Abwesen- 

30 heit einer Softwarekomponente SW ttberprufen, sondern auch oJ 
eine Softwarekomponente gerade lauft bzw. ausgeftihrt wird ode: 
nicht. Alle diese Varianten werden in der vorliegenden Be- 
schreibung unter dem Begriff- „An- oder Abwesenheit" zusammenge- 
faBt bzw. sind eine der moglichen Voraussetzungen fur ein* 

35 Softwarekomponente, die ein Detektor DET tiberprxifen kann. 
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Die Detektoren DET k6nnen sich auch gegenseitig aufrufer. 
bzw. voneinander Gebrauch machen, z.B. wenn eine zu uberprti- 
fende Voraussetzung in mehrere einzelne Voraussetzungen zerleg- 
bar ist, fur welche bereits andere Detektoren vorhanden sind. 
5 Anlage 1 zeigt ein Implementierungsbeispiel fur einen De- 

tektor zur Feststellung der Anwesenheit der Software komponente 

♦ 

^Microsoft Word 10. 0 M der Firma Microsoft. Die Subroutine 
„query_exist" tiberpriift die Anwesenheit der Sof tware komponente; 
die Subroutine ^query^active^, ob die Sof twarekomponente lauft. 

10 Jede der Routinen 4, 4', 5, 5' kann vorteilhaf terweise sc 

gestaltet werden, dafi sie selbst bzw. mittels entsprechendei 
Detektoren DET uberprtift, ob sie fur die auf dem Benutzerrech- 
ner 2 vorgefundene Hardware- oder Sof twareausstattung geeignet 
ist und f wenn nicht, beispielsweise ohne weitere Aktion beendet 

15 wird, d.h. die Steuerung zurttckgibt. Auch kann die Routine 
uberpriifen, ob die aufgerufene Installation, Deinstallation, 
Konf iguration oder Dekonf iguration ihrer Sof twarekomponente 
nicht ohnehin bereits erfolgt ist, in welchem Fall sie eben- 
falls beendet wird, d.h. die Steuerung zuriickgibt. Alternati^ 

20 konnten diese Prufungen aber auch in einen den Routinen gemein- 
samen Codeabschnitt (siehe oben) des Regelpakets RP oder in der 
aufrufenden ProzeJJ P (siehe unten) verlagert sein. 

Schliefilich umfafit das Framework FW eine Liste L jener Re- 
gelpakete RP, mit deren Abarbeitung im Benutzerrechner 2 begon- 

25 nen werden soli. Es versteht sich, dafi die Liste L z.B. nur auf 
das erste Regelpaket RP verweisen kann, welches in weitere Re- 
gelpakete RP rekursiert, oder einfach alle Regelpakete RP an- 
ftihrt, wenn diese jeweils fiir sich die Voraussetzungen far ihre 
Ausfuhrung feststellen, oder aber nur solche Regelpakete an- 

30 fuhrt, die von einem Administrator als „Tagespensum" vorgegeber 
werden usw. 

In einer bevorzugten Implementierung besteht ein Regelpa- 
ket RP aus einem Satz von Dateien, die durch eine zentrale Re- 
gelpaket-Spezif izierungsdatei referenziert werden. Ein Beispie] 
35 einer solchen Regelpaket-Spezif izierungsdatei ist in Anlage 2 
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angefiihrt. Im Einleitungsabschnitt der Datei ist der Verwei 
auf die Software komponente ersichtlich; die Verweise „install" 
^uninstaller „policies_true xv und „policies_f alse" zeigen au 
die vier Routinen 4, 4', 5 bzw. 5' • 
5 Die Auswertung des Frameworks FW und Abarbeitung der Re 

gelpakete RP auf dem Benutzerrechner 2 wird mit Hilfe eine 
Klientprogramms KP durchgef tihrt, welches die beschriebene Abar 
beitung der Liste L in einem Prozefi P durchfuhrt (Fig. 2) . Z 
diesem Zweck enthait das Klientprogramm KP einen Speicher S zu. 

10 lokalen Speicherung einer Kopie des Frameworks FW, welcher auci 
far die Weiterverteilung (Replikation) des Frameworks FW an an 
dere Benutzerrechner 2 verwendet werden kann. 

Das Klientprogramm KP verftigt ferner ttber eine lokale Da- 
tenbank DB, welche zwei Listen 7, 8 fUhrt, deren Verwendung ii 

15 den Fig. 7 und 8 ausf Qhrlicher gezeigt ist. Die erste Liste ' 
enthait einen Eintrag fUr jedes Regelpaket RP, dessen Installa- 
tionsroutine 4 erfolgreich durchlaufen wurde. Die zweite List* 
8 enthSlt einen Eintrag fur jedes Regelpaket RP, dessen Konfi- 
gurationsroutine 5 erfolgreich durchlaufen wurde. Damit verftigi 

20 das Klientprogramm KP uber eine Aufstellung aller auf dem Be- 
nutzerrechner 2 erfolgreich installierten und konf igurierte] 
Softwarekomponenten SW, welche bei der Abarbeitung der Regelpa- 
kete RP auch dazu verwendet werden kann, Doppelauf ruf e ode: 
endlose Rekursionen usw. zu erkennen und zu vermeiden. Darube; 

25 hinaus ist die lokale Datenbank DB auch nutzlich, um obsolete 
oder veraltete Softwarekomponenten zu erkennen und zu entfer- 
nen, wie im Rahmen des Flufidiagramms von Fig. 6 noch ausftthr- 
lich erlautert wird. 

Fig. 6 zeigt ein beispielhaf tes Fluftdiagramm fur daj 

30 Klientprogramm KP. Nach einer Initialisierung im Block 9 werdei 
im Block 10 alle in der Liste L des Frameworks FW angeftihrtei 
Regelpaket e RP abgearbeitet, und zwar durch Auf ruf en ihrer In- 
stallationsroutinen 4. Es versteht sich, daft dabei die Regelpa- 
kete RP, wenn sie mittels der Detektoren DET die Voraussetzun< 

35 der Anwesenheit oder Abwesenheit anderer Regelpakete RP fest- 
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stellen f jeweils in diese anderen Regelpakete rekursieren, wie 
bereits erlautert . 

Nachdem im Block 10 alle Installationsroutinen 4 
abgearbeitet und damit alle erforderlichen Sof twarekomponenten 
5 BS1, A, B, . . auf dem Benutzerrechner 2 installiert worden sind, 
geht das Klientprogramm KP bzw. sein ProzeJB P zum Block 11 
tiber, in welchem die Konf iguration der Sof twarepakete in einem 
zweiten Durchlauf durch die Liste L erfolgt. Im Block 11 werden 
wieder die in der Liste L angefiihrten Regelpakete RP abgearbei- 

10 tet f diesmal unter Aufrufen ihrer Konf igurationsroutine 5, 
Falls erforderlich, konnen die Regelpakete RP wieder in weitere 
Regelpakete rekursieren, wie bereits er6rtert, 

Dadurch, dali im Block 10 zunachst eine vollstandige In- 
stallation aller erforderlichen Sof twarekomponenten erfolgt , 

15 wird gewahrleistet, dali das Konf igurieren im Block 11 von einem 
definierten Systemzustand ausgeht, was in vielen Fallen eine 
korrekte Konf iguration erst erm&glicht . 

Die weiteren in Fig. 6 gezeigten Blocke 12 und 13 des Ver- 
fahrens bzw, des Klientprogramms KP sind optional und dienen 

20 der Beseitigung obsoleter Oder veralteter Sof twarekomponenten 
vom Benutzerrechner 2. 

Wie bereits erwShnt, sind Regelpakete RP fur obsolete oder 
veraltete Sof twarekomponenten nicht mehr im Framework FW ent- 
halten, , k6nnen allerdings auf einem Benutzerrechner 2 noch er- 

25 forderlich sein f beispielsweise wegen veralteter Hardwareaus- 
stattung. Das Klientprogramm KP vergleicht daher die im Frame- 
work FW enthaltenen Regelpakete RP mit den in den Listen 7 und 
8 der lokalen Datenbank DB eingetragenen Regelpaketen RP und 
versetzt jene Regelpakete RP, welche im Framework FW nicht mehr 

30 aufscheinen, in einen inaktiven Zustand, z,B. durch ein ent- 
sprechendes Flag in den Listen 7 und 8 oder im Regelpaket RP 
selbst. Im inaktiven Zustand ist ein Regelpaket RP nur mehr an- 
hand seiner Deinstallationsroutine 4' oder seiner Dekonf igura- 
tionsroutine 5' aufrufbar. 
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Im Block 12 werden alle inaktiven Regelpakete RP anhan 
ihrer Dekonf igurationsroutinen 5' aufgerufen. Im anschlieBende 
Block 13 erfolgt ein erneuter Durchgang anhand ihrer Deinstal 
lationsroutinen 4'. 
5 Wie bereits erSrtert, priift dabei jede Deinstallations 

oder Dekonf igurationsroutine (oder auch der Prozefl P) , ob si 
auf ihr „Ziel x \ den Benutzerrechner 2, anwendbar ist und nu 
dann r wenn dies moglich ist (z.B. Ausbau einer veralteten Hard 
ware) , wird sie ausgeftthrt. Bei der Dekonf iguration bzw. Dein 

10 stallation tr£gt sie sich auch jeweils wieder aus der Liste 
bzw. 8 der lokalen Datenbank DB aus. 

Dadurch wird bei jedem Durchlauf des Klientprogramms K 
gleichsam ein Reinigungsdurchlauf ausgefdhrt, der veraltetn 
oder obsolete Sof twarekomponenten und deren Regelpakete besei 

15 tigt. 

Im Block 14 des Flufidiagranuns von Fig. 6 werden Abschlufi- 
prozesse durchgefiihrt und das Klientprogramm KP beendet. 

Das Ausftihren des Klientprogramms KP auf dem Benutzerrech- 
ner 2 kann auf vielerlei Arten angestofien werden. Fig. 9 zeig* 
20 einige mSgliche Varianten. Dem AbarbeitungsprozeJS P des Klient- 
programms KP ist hier ein Ereignismanager 15 vorgeschaltet 
welcher sowohl lokale Ereignisse auf dem Benutzerrechner 2 al: 
auch entfernte Ereignisse z.B. auf den Wartungsarbeitsplatzen : 
verarbeiten kann. 

25 Sinnbildlich sind einige Arten von lokalen Ereignissen : 

dargestellt, beispielsweise Benutzerereignisse 16 wie die Beta- 
tigung einer entsprechenden Taste, Systemereignisse 17 wie da: 
Erkennen eines Systems tarts oder -stops, einer Benutzeran- ode: 
-abmeldung, einer Netzwerkan- oder -abmeldung, eines Programm- 

30 starts oder -endes usw., Hardwareereignisse 18 wie das An- ode: 
Abschliefien einer Hardwareausstattung, oder vom Systemadmini- 
strator definierte lokale Ereignisse 19. Es ist aber auch mog- 
lich, dafi das Klientprogramm KP durch entfernte Ereignisse aus- 
gelGst wird, beispielsweise durch aktives Senden eines Trigger- 

35 befehls von einer Wartungsarbeitsstation 3 her, oder durcl 
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//passives* Abholen eines Auslosebef ehls von einer Netzwerkres- 
source RES if z.B. im Zuge einer Netzwerkanmeldung oder zu vor- 
gegebenen Tageszeiten. 

Die genannten Ereignisse konnen auch direkt die Ausfuhrung 
5 bestiinmter Regelpakete RP Oder Routinen 4, 4' , 5, 5 f ausl6sen, 
und zwar uber deren AuslSseverweise TRIG (siehe Fig. 4) . Der 
Ereignismanager 15 des Klientprogramms KP kann direkt die uber 
die Ausloseverweise TRIG zugeordneten Regelpakete oder Routinen 
aufrufen, oder tiber die Listen 7, 8 der lokalen Datenbank DB, 

10 in welche die Regelpakete RP ihre Ausl6severweise TRIG einge- 
tragen haben, Auch ist es moglich, nach einem Auslosen des Er- 
eignismanagers 15 bereits im Block 9 des Klientprogramms KP 
jene Regelpakete - entsprechend ihren Ausl5severweisen TRIG - 
vorzuselektieren, welche der Ereignisausldsung des Ereignisma- 

15 nagers 15 entsprechen, und anschliefiend das Klientprogramm 15 
nur f(lr diese vorselektierten Regelpakete RP zu durchlaufen. 

Eine andere Moglichkeit ist es, die Ausloseverweise TRIG 
in den Regelpaketen RP als „Filter* far die Abarbeitung der Re- 
gelpakete im Zuge einer ereignisgesteuerten Ausfuhrung des 

20 Klientprogramms KP zu verwenden: Wenn ein Regelpaket zumindest 
einen Ausl6severweis TRIG enthalt, wird es bei einem Aufruf 
durch das Klientprogramm KP nur dann ausgeftihrt, wenn auch sein 
Ausl6severweis TRIG diesem Ereignis entspricht. 

Fig, 10 zeigt ein Implementierungsbeispiel des Klientpro- 

25 gramms KP im Rahmen eines Betriebssystems eines Benutzerrech- 
ners 2, welches geschtitzte Bereiche („Kontexte*) fur einzelne 
Prozesse bereitstellt , beispielsweise urn Benutzerprozesse von 
Systemprozessen zu isolieren und dadurch die Betriebsstabilitat 
zu verbessern. Da die Installation und Konf iguration von Soft- 

30 warekomponenten hclufig kontextubergreif ende Berechtigungen er- 
fordert/ wird hier der Abarbeitungsprozefi P in mehrere in ge- 
schiitzten Systembereichen Admin*/ „User* und //System* ablau- 
fende Ausf uhrungsmaschinen Pi, P 2 und P 3 unterteilt. 

Fur jede systemmodif izierende Komponente des Verfahrens, 

35 beispielsweise die Routinen der Regelpakete, kann ein Transak- 



tionssystem implement iert werden, welches einen vollstandigei 
Rollback der Systemkonf iguration ermoglicht, falls die Instal- 
lation, Deinstallation, Konf iguration oder Dekonf iguration ei- 
ner Sof twarekomponente fehlschiagt- 

Die Erfindung ist nicht auf die dargestellten Ausfiihrungs- 
formen beschr&nkt, sondern umfafit alle Varianten und Modifika- 
tionen, die in den Rahmen der angeschlossenen Anspriiche fallen 
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ANLAGE 1 

< 

[sml::header] 
sralversion=3.0.0 
encoding=iso-8859- 1 
type=dsf 

objectid~3-All-100A-57F0-1000C00000l-0-0 
sqn=3-FFFF- 1 00 A-57F0-25-0-0 
name=Microsoft Office XP Premium Edition 

[dsf.rqueryjexist] 

t* detect Office 10.0 components */ 
if .reg.keyexist condition:true^ 

>reghi ve=HKEY_LOC AL JV1ACH 1 0.0, 

{ 

do.reg.setkey 
regkeyhandle:hRegistry,reghi^ 
dMnstallRoo^option^PEN, 

if.sys.handleisvalid condition:true regkeyhandleihRegistry, 

{ 

;detect WinWord 

;first ler/s see if the required file exists 
if.fi le.exi st condition:false,-> 
.^fi!epath=<!-get.reg. value regkeyha^^ 

{ 

do.sys.exit->level= = section,returnvalue :: =false, 

} 

;second let's check die files required property 
if.file.matchversionproperty condition: false,-> 

.->filepath=<!~getreg. value regkeyhandle:hRegistry,->regenti7=Path > -!>WrNWORD.EXE, 
.opropertyname^fileversion, versionproperty type:eq,-10.*, 

{ 

do.sys.exit->Ievel=section,returnvalue=false s 

} 

do.sys.closehandle regkeyhandle:hRegistry, 

} 

} 

[dsf::query_active] 

/* dedect if Office 1 0.0 WinWord component is running */ 
if.reg.keyexist conditionttrue,- 

>reghive=HKEY LOCAL_MACHINE/egpath=SOFTWARE\Microsoft\Office\10.0, 
{ 

do.reg.setkey 
regkeyhandle:hRegistry s regW^^ 
d\InstollRoot,option-OPEN, 

if.sys.handleisvalid condition: true regkeyhand]e:hRegistry, 

{ 

;dedect WinWord 

ifprocess.exist condition: false,-c>processname= WIN WORD.EXE, moduIe=<!— getreg. value 
regkeyhandle:hRegistry,^regentr^ 

{ 

calI.sys.exit->level=section > returnvalue=false, 

} 

calLsys.closehandle regkeyhandleihRegistry, 

} 

} 
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ANLAGE 

[sml::header] 
smlversion^O.O 
encoding=iso-8859-l 
type=psf 

objectid=3-3 F 1 - 1 00A-57F0- 1 0O0C00000 1 -0-0 
sqn=3-FFFF-l 0OA-57FO-2-O-0 
name=Microsoft Office XP Premium 

■ 

[psf: definition] 

packagename-^text^Microsoft Office XP, 

packagedescription->text=The Microsoft Office XP Premium Suite, 
packagecompany^>textr=Microsoft, 

packagecopyright->text=Copyrig)it<D Microsoft Corporation 1985*2001. All rights reserved, 

packageproductversion^versionnumber^lO.O, 

packagedate->text=20 02-0 1-01, 

[sml::system] 

transactioncontext->context=package, 

securitycontext->context=ADM, 

oscorttext->context=Win32, 

[smI::os5upport] 

windowssys->platform=x86,os=nt,osversion type:=y=5.0 9 sp type.^^3, 
windowssys->platform=x86,os=nt > osverston type:==5. 1 ,sp type:>=,= I , 
winesys->platform=x86,wineversion type:>=,=<2.0.0,winetype=<:ROSSOVER_OFFICE, 

[psfr.detectself] 

detectsoftware->objectid=3-A 11-1 00A-57F0- 1 000C00000 1 -0-0, 

[sml::displaysupport] 
display->show=l , 

displayheader->text=Microsoft Office XP, 
displaytext->text=Manages Microsoft Office XP..., 

tpsf::archive] 

archivepo!icies->archive==l joverride^l, 
archiveuninstall->archive=l, 

[psf::insta!loptions] 
rollbackonerror->ro!lback=l , 
installevents->event=ALL, 
ownersonly->restrict=0, 

[psf::dedecttargets] 

if group.accountismember-ogroupname groupformatrdefault, type:eq,=officexp, 
[psf::install] 

instalIjobid->objectid»3-4 1 1 - 1 00A-57F0- 1 000C00000 1 -0-0, 
[psfr:uninstall] 

uninstaltjobid->objectid=3 -44 1 - 1 00 A-57F0- 1 000C000OO 1-0-0, 
[psf::poIicies_trueJ 

policyid->objectid==3-47 1 - 1 00A-57F0- 1 000C00000 1 -0-0, 
[psf: :policies__faIse] 

policyid->objectid==3-47 1 - 1 00A-57FO- 1 OOOC000002-0-0 
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Patentanspruche : 

1. Verfahren zur automatischen Installation un 
Konf iguration von Sof twarekomponenten (SW) in einem Computer 
5 netzwerk (1) , das eine Vielzahl von Benutzerrechnern (2) un 
zumindest eine Netzwerkressource <RES) von installierbare 
Softwarekomponenten umfafit, wobei die erfolgreiche Installatio 
einer Sof twarekomponente die An- oder Abwesenheit einer andere 
Sof twarekomponente voraussetzen kann, gekennzeichnet durch di 
10 Schritte: 

a) Bereitstellen eines Frameworks (FW) auf der Netzwerk 
ressource (RES), welches ein Regelpaket (RP) fur jede instal 
lierbare Softwarekomponente (SW) , einen Detektor (DET) fur jed 
mogliche Voraussetzung und eine Liste (L) abzuarbeitender Re 

15 gelpakete (RP) umfafit, 

wobei jedes Regelpaket (RP) zumindest eine der folgende 
vier Routinen umfalit: eine Routine (4) zum Installieren de 
Softwarekomponente (SW) auf dem Benutzerrechner (2), eine Rou 
tine (4 f ) zum Deinstallieren derselben, eine Routine (5) zu; 

20 Konf igurieren der installierten Softwarekomponente (SW) un 
eine Routine (5') zum Ruckgangigmachen (Dekonf igurieren) de 
Konf iguration hinsichtlich derselben; 

b) Obertragen des Frameworks (FW) an einen Benutzerrech 
ner (2); 

25 c) Abarbeiten der Liste (L) abzuarbeitender Regelpaket* 

(RP) auf dem Benutzerrechner (2) unter Aufrufen ihrer Installa 
tionsroutinen (4), und iiochmaliges Abarbeiten der Liste (L) ab 
zuarbeitender Regelpakete auf dem Benutzerrechner (2) unte. 
Aufrufen ihrer Konf igurationsroutinen (5) ; 

30 wobei f wenn im Zuge eines Regelpakets (RP) mittels eine. 

Detektors (DET) festgestellt wird, daft die An- oder Abwesenhei 
einer anderen Softwarekomponente (SW) erforderlich ist, die In 
stallations- bzw. Deinstallationsroutine (4, 4') des dieser an- 
deren Softwarekomponente (SW) zugeordneten Regelpakets (RP 

35 aufgerufen wird. 
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2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, 
dafi das Framework (FW) auch Detektoren (DETrw, DET B si) fur die 
Hardware- oder Betriebssystemausstattung eines Benutzerrechners 
(2) umfafit und ini Zuge einer Routine (4 f 4', 5, 5') mittels ei- 

5 nes solchen Detektors iiberpriift wird, ob der Benutzerrechner 
(2) fur die jeweilige Installation, Deinstallation, Konfigura- 
tion oder Dekonf iguration der Sof twarekomponente (SW) geeignet 
ist. 

3. Verfahren nach Anspruch 1 oder 2, dadurch 
10 gekennzeichnet, daft im Zuge einer Routine (4, 4', 5 r 5') vorab 

geprtift wird r ob die jeweilige Installation, Deinstallation, 
Konf iguration oder Dekonf iguration der Sof twarekomponente (SW) 
auf dem Benutzerrechner (2) bereits erfolgt ist und, wenn ja, 
die Routine sofort beendet wird. 

15 4. Verfahren nach einem der Anspriiche 1 bis 3, dadurch 

gekennzeichnet, daB Schritt b) und/oder Schritt c) durch ein 
lokales Ereignis (16-19) auf dem jeweiligen Benutzerrechner (2) 
ausgelQst wird, z.B. ein Systemereignis wie ein Systemstart 
oder -stop, eine Benutzeran- oder -abmeldung, eine Netzwerkan- 

20 oder -abmeldung, ein* Programmstart oder -ende usw., ein Hard- 
wareereignis wie das An- oder AbschlieJJen einer Hardwareaus- 
stattung, usw, 

5. Verfahren nach einem der Ansprtiche 1 bis 4, dadurch 
gekennzeichnet, dali Schritt b) und/oder Schritt c) durch ein 

25 entferntes Ereignis auf der Netzwerkressource ausgelSst wird, 
z.B. das Aussenden einer Gruppen- oder Broadcastnachricht usw. 

6. Computerprogramm, implementierend ein Verfahren nach 
einem der Ansprtiche 1 bis 5. 

7. Regelpaket, das auf einem Betriebssystem eines Benut- 
30 zerrechners (2) ausftihrbar ist, zur automatischen Installation 

und Konf iguration von Sof twarekomponenten (SW), die auf einer 
Netzwerkressource (RES) verfiigbar sind, auf dem Benutzerrechner 
(2), dadurch gekennzeichnet, dafi das Regelpaket (RP) einen Ver- 
weis (RESa) auf eine Sof twarekomponente auf der Netzwerkres- 
35 source (RES) und zumindest eine der folgenden vier Routinen um- 
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falit: eine Routine (4) zum Installieren dieser Softwarekompc 
nente (SW) auf dem Benutzerrechner (2), eine Routine (4') zc 
Deinstallieren dieser Softwarekomponente (SW) vom Benutzerrech 
ner (2) f eine Routine (5) zum Konf igurieren dieser auf dem Be 
5 nutzerrechner (2) installierten Sof twarekomponente (SW) , un 
eine Routine (5') zum RiickgSngigmachen (Dekonf igurieren) de 
Konfiguration dieser auf dem Benutzerrechner (2) installierte 
Softwarekomponente (SW) , wobei jede Routine (4, 4' , 5, 5') 
wenn sie das Erfordernis der An- oder Abwesenheit einer andere 
10 Softwarekomponente (SW) feststellt, zur Installations- bzw 
Deinstallationsroutine (4, 4') eines dieser anderen Software 
komponente (SW) zugeordneten anderen Regelpakets (RP) vei 
zweigt . 

8. Regelpaket nach Anspruch 7, dadurch gekennzeichnet 
15 daii es einen Verweis (DEThw, DET BS i) auf eine bestimmte Hard 

ware- und/oder Betriebssystemausstattung eines Benutzerrechner 
(2) umfaBt und anhand dieses Verweises ttberpruft, ob der Benut 
zerrechner (2) fttr die jeweilige Installation, Deinstallation 
Konfiguration oder Dekonf igurat ion der Softwarekomponente (SW 
20 geeignet ist. 

9. Regelpaket nach Anspruch 7 oder 8, dadurc 
gekennzeichnet , dafi es tiberpriift, ob die jeweilige Installa 
tion, Deinstallation, Konfiguration oder Dekonf iguration de 
Softwarekomponente (SW) auf dem Benutzerrechner (2) bereits er 

25 folgt ist und, wenn ja, seine Ausfiihrung beendet. 

10. Regelpaket nach einem der Ansprliche 7 bis 9, dadurc 
gekennzeichnet, daB es mindestens einen Auslaseverweis (TRIG 
auf ein lokales Ereignis (16-19) auf dem Benutzerrechner (2 
oder ein entferntes Ereignis auf der Netzwerkressource enthait 

30 wobei der Ausloseverweis (TRIG) diesem Ereignis zumindest ein 
der Routinen (4, 4', 5, 5' ) des Regelpakets zuordnet. 

11. Regelpaket nach einem der Anspruche 7 bis 10 , dadurc 
gekennzeichnet, dafi * es in einen inaktiven Zustand versetzba 
ist, in welchem nur seine Deinstallations- und Dekonf igurati 

35 onsroutinen (4', 5') aufrufbar sind. 



r 
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12. Computer, der mit zumindest einem Regelpaket nach ei- 
nem der Anspriiche 7 bis 11 programmiert 1st. 

13. Framework, das auf einer Netzwerkressource (RES) ir 
einem Computernetzwerk (1) far eine Vielzahl von Benut zerrech- 

5 nern (2) bereitstellbar ist, zur automat ischen Installation unc 
Konf iguration von auf der Netzwerkressource (RES) verfiigbarer 
Sof twarekomponenten (SW) auf den Benutzerrechnern (2) , wobei 
die erfolgreiche Installation einer Sof twarekomponente (SW) die 
An- oder Abwesenheit einer anderen Sof twarekomponente (SW) vor- 

10 aussetzen kann, dadurch gekennzeichnet , dafi das Framework (FW) 
einen Satz von Regelpaketen (RP) nach einem der Anspriiche 7 bis 
10, einen Satz von Detektoren (DET) fiir jede mogliche Voraus- 
setzung, und eine Liste (L) von auf den Benutzerrechnern (2) 
abzuarbeitenden Regelpaketen (RP) umfafit. 

15 14. Framework nach Anspruch 13 in Verbindung mit einen 

Regelpaket nach Anspruch 8, dadurch gekennzeichnet, dali das 
Framework (FW) auch Detektoren (DEThw* DET B si) fur die Hardware- 
oder Betriebssystemausstattung eines Benut zerrechners (2) um- 
faftt und den Regelpaketen (RP) fur die genannte Oberpriif ung zuj 

20 Verfugung stellt. 

15. Computer, der mit einem Framework nach Anspruch 12 
oder 14 programmiert ist. 

16. Maschinenlesbarer Datentrager, der mit einem Frameworl 
nach Anspruch 13 oder 14 programmiert ist. 

25 17. Klientprogramm, das auf einem Benut zerrechner (2) 

ausfiihrbar ist, zur automatischen Installation und Konf igura- 
tion von Softwarekomponenten (SW) , die auf einer Netzwerkres- 
source (RES) verfiigbar sind, auf dem Benut zerrechner (2) , da- 
durch gekennzeichnet, daB es ein Framework (FW) nach Ansprucl 

30 13 oder 14 empfangt und speichert, in einem ersten Durchganc 
die Liste (L) abzuarbeitender Regelpakete (RP) unter Aufrufer 
ihrer Installationsroutinen (4) und in einem zweiten Durchganc 
die Liste (L) abzuarbeitender Regelpakete (RP) unter Aufrufer 
ihrer Konf igurationsroutinen (5) abarbeitet. 
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18. Klientprograrnm nach Anspruch 17, dadurch gekennzeich 
net, dafi es eine lokale Datenbank (DB) aufweist, welche ein 
Liste (7) von Regelpaketen (RP) mit erfolgreich durchlaufene 

« Installationsroutinen (4) und eine Liste (8) von Regelpakete 

5 (RP) mit erfolgreich durchlaufenen Konf igurationsroutinen (5 
enthalt . 

19. Klientprograrnm nach Anspruch 18 , dadurch gekennzeich 
net, dafi es die in den Listen (7 , 8) eingetragenen Regelpaket 
(RP) mit den im Framework (FW) enthaltenen Regelpaketen (RP 

10 vergleicht und ftir jene Regelpakete (RP) , welche im Framewor 
(FW) nicht aufscheinen, in einem ersten Durchgang deren Dekon 
f igurationsroutinen (5') und in einem zweiten Durchgang dere 
Deinstallationsroutinen (4') abarbeitet. 

20. Klientprograrnm nach einem der Anspruche 17 bis 19 i 
15 Verbindung mit einem Regelpaket nach Anspruch 10, dadurch ge 

kennzeichnet, dafi es das Auftreten eines lokalen Ereignisse 
(16-19) auf dem Benutzerrechner (2), z.B. eines Systemereignis 
ses wie eines Systerastarts oder -stops, einer Benutzeran-. ode 
-abmeldung, einer Netzwerkan- oder -abrneldung, eines Programm 

20 starts oder -endes usw., eines Hardwareereignisses wie des An 
oder Abschliefiens einer Hardwareausstattung, usw., und/oder ei 
nes entfernten Ereignisses auf der Netzwerkressource, z.B. de 
Aussendens einer Gruppen- oder Broadcastnachricht usw., tiber 
wacht und die diesem Ereignis tiber den Ausldseverweis (TRIG 

25 zugeordnete Routine (4, 4', 5, 5' ) des entsprechenden Regelpa 
kets (RP) aufruft. 

21. Klientprograrnm nach einem der Anspruche 17 bis 20 
dadurch ge kennzeichnet, dafi es ein Transaktionssystem fur jed- 
systemmodifizierende Komponente, insbesondere fur die Regelpa 

30 kete (RP) , aufweist. 

22. Computer, der mit einem Klientprograrnm nach einej 
der Anspruche 17 bis 21 programmiert ist. 
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Zusammenf assung : 

Verfahren zur Installation und Konf iguration 
5 von Software komponent en 

Die Erfindung betrif ft ein Verfahren, Regelpaket (RP) / 
Framework (FW) und Klientprogramm (KP) zur automatischen In- 
stallation und Konf iguration von Sof twarekomponenten (SW) in 
10 einem Computernetzwerk (1) , das eine Vielzahl von Benutzerrech- 
nern (2) und zumindest eine Net zwerkres source (RES) von instal- 

■ 

lierbaren Sof twarekomponenten (SW) umfalit, wobei die erfolgrei- 
che Installation einer Sof twarekomponente (SW) die An- oder Ab- 
wesenheit einer anderen Sof twarekomponente (SW) voraussetzen 

15 kann, sowie entsprechend programmierte Computer und DatentrS- 
ger. Insbesondere weist jedes Regelpaket (RP) zumindest eine 
der folgenden vier Routinen auf: eine Routine (4) zum Instal- 
lieren der Sof twarekomponente (SW) auf dem Benutzerrechner (2), 
eine Routine (4') zum Deinstallieren derselben, eine Routine 

20 (5) zum Konf igurieren der installierten Sof twarekomponente (SW) 
und eine Routine (5' ) zum RUckgangigmachen (Dekonf igurieren) 
der Konf iguration derselben, wobei die Regelpakete (RP) auf dem 
Benutzerrechner (2) unter Aufrufen ihrer Installationsroutinen 
(4) und anschlieJiend ihrer Konf igurationsroutinen (5) abgear- 

25 beitet werden. 
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